home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1993 / Internet Info CD-ROM (Walnut Creek) (1993).iso / inet / rfc / rfc1145 < prev    next >
Encoding:
Text File  |  1991-04-20  |  10.5 KB  |  283 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                          J. Zweig
  8. Request for Comments: 1145                                         UIUC
  9.                                                            C. Partridge
  10.                                                                     BBN
  11.                                                           February 1990
  12.  
  13.  
  14.                      TCP Alternate Checksum Options
  15.  
  16. Status of This Memo
  17.  
  18.    This memo suggests a pair of TCP options to allow use of alternate
  19.    data checksum algorithms in the TCP header.  The use of these options
  20.    is experimental, and not recommended for production use.
  21.  
  22.    Distribution of this memo is unlimited.
  23.  
  24. Introduction
  25.  
  26.    Some members of the networking community have expressed interest in
  27.    using checksum-algorithms with different error detection and
  28.    correction properties than the standard TCP checksum.  The option
  29.    described in this memo provides a mechanism to negotiate the use of
  30.    an alternate checksum at connection-establishment time, as well as a
  31.    mechanism to carry additional checksum information for algorithms
  32.    that utilize checksums that are longer than 16 bits.
  33.  
  34. Definition of the Options
  35.  
  36.    The TCP Alternate Checksum Request Option may be sent in a SYN
  37.    segment by a TCP to indicate that the TCP is prepared to both
  38.    generate and receive checksums based on an alternate algorithm.
  39.    During communication, the alternate checksum replaces the regular TCP
  40.    checksum in the checksum field of the TCP header.  Should the
  41.    alternate checksum require more than 2 octets to transmit, the
  42.    checksum may either be moved into a TCP Alternate Checksum Data
  43.    Option and the checksum field of the TCP header be sent as 0, or the
  44.    data may be split between the header field and the option.  Alternate
  45.    checksums are computed over the same data as the regular TCP checksum
  46.    (see TCP Alternate Checksum Data Option discussion below).
  47.  
  48. TCP Alternate Checksum Request Option
  49.  
  50.    The format of the TCP Alternate Checksum Request Option is:
  51.  
  52.                  +----------+----------+----------+
  53.                  |  Kind=14 | Length=3 |  chksum  |
  54.                  +----------+----------+----------+
  55.  
  56.  
  57.  
  58. Zweig & Partridge                                               [Page 1]
  59.  
  60. RFC 1145             TCP Alternate Checksum Options        February 1990
  61.  
  62.  
  63.    Here chksum is a number identifying the type of checksum to be used.
  64.  
  65.    This option is not copied into each fragment, and appears only in the
  66.    first fragment.
  67.  
  68.    The currently defined values of chksum are:
  69.  
  70.                    0  -- TCP checksum
  71.                    1  -- 8-bit  Fletcher's algorithm (see Appendix I)
  72.                    2  -- 16-bit Fletcher's algorithm (see Appendix II)
  73.  
  74.    Note that the 8-bit Fletcher algorithm gives a 16-bit checksum and
  75.    the 16-bit algorithm gives a 32-bit checksum.
  76.  
  77.    Alternate checksum negotiation proceeds as follows:
  78.  
  79.       A SYN segment used to originate a connection may contain the
  80.       Alternate Checksum Request Option, which specifies an alternate
  81.       checksum-calculation algorithm to be used for the connection.  The
  82.       acknowledging SYN-ACK segment may also carry the option.
  83.  
  84.       If both SYN segments carry the Alternate Checksum Request option,
  85.       and both specify the same algorithm, that algorithm must be used
  86.       for the remainder of the connection.  Otherwise, the standard TCP
  87.       checksum algorithm must be used for the entire connection.  Thus,
  88.       for example, if one TCP specifies type 1 checksums, and the other
  89.       specifies type 2 checksums, then they will use type 0 (the regular
  90.       TCP checksum).  Note that in practice, one TCP will typically be
  91.       responding to the other's SYN, and thus either accepting or
  92.       rejecting the proposed alternate checksum algorithm.
  93.  
  94.       Any segment with the SYN bit set must always use the standard TCP
  95.       checksum algorithm.  Thus the SYN segment will always be
  96.       understood by the receiving TCP.  The alternate checksum must not
  97.       be used until the first non-SYN segment.  In addition, because RST
  98.       segments may also be received or sent without complete state
  99.       information, any segment with the RST bit set must use the
  100.       standard TCP checksum.
  101.  
  102.       The option may not be sent in any segment that does not have the
  103.       SYN bit set.
  104.  
  105.       An implementation of TCP which does not support the option should
  106.       silently ignore it (as RFC 1122 requires).  Ignoring the option
  107.       will force any TCP attempting to use an alternate checksum to use
  108.       the standard TCP checksum algorithm, thus ensuring
  109.       interoperability.
  110.  
  111.  
  112.  
  113.  
  114. Zweig & Partridge                                               [Page 2]
  115.  
  116. RFC 1145             TCP Alternate Checksum Options        February 1990
  117.  
  118.  
  119. TCP Alternate Checksum Data Option
  120.  
  121.    The format of the TCP Alternate Checksum Data Option is:
  122.  
  123.                 +---------+---------+---------+     +---------+
  124.                 | Kind=15 |Length=N |  data   | ... |  data   |
  125.                 +---------+---------+---------+     +---------+
  126.  
  127.    This field is used only when the alternate checksum that is
  128.    negotiated is longer than 16 bits.  These checksums will not fit in
  129.    the checksum field of the TCP header and thus at least part of them
  130.    must be put in an option.  Whether the checksum is split between the
  131.    checksum field in the TCP header and the option or the entire
  132.    checksum is placed in the option is determined on a checksum by
  133.    checksum basis.
  134.  
  135.    The length of this option will depend on the choice of alternate
  136.    checksum algorithm for this connection.
  137.  
  138.    This option is not copied into each fragment, and appears only in the
  139.    first fragment.
  140.  
  141.    While computing the alternate checksum, the TCP checksum field and
  142.    the data portion TCP Alternate Checksum Data Option are replaced with
  143.    zeros.
  144.  
  145.    An otherwise acceptable segment carrying this option on a connection
  146.    using a 16-bit checksum algorithm, or carrying this option with an
  147.    inappropriate number of data octets for the chosen alternate checksum
  148.    algorithm is in error and must be discarded; a RST-segment must be
  149.    generated, and the connection aborted.
  150.  
  151.    Note the requirement above that RST and SYN segments must always use
  152.    the standard TCP checksum.
  153.  
  154. APPENDIX I:  The 8-bit Fletcher Checksum Algorithm
  155.  
  156.    The 8-bit Fletcher Checksum Algorithm is calculated over a sequence
  157.    of data octets (call them D[1] through D[N]) by maintaining 2
  158.    unsigned 1's-complement 8-bit accumulators A and B whose contents are
  159.    initially zero, and performing the following loop where i ranges from
  160.    1 to N:
  161.  
  162.            A := A + D[i]
  163.            B := B + A
  164.  
  165.    It can be shown that at the end of the loop A will contain the 8-bit
  166.    1's complement sum of all octets in the datagram, and that B will
  167.  
  168.  
  169.  
  170. Zweig & Partridge                                               [Page 3]
  171.  
  172. RFC 1145             TCP Alternate Checksum Options        February 1990
  173.  
  174.  
  175.    contain (N)D[1] + (N-1)D[2] + ... + D[N].
  176.  
  177.    The octets covered by this algorithm should be the same as those over
  178.    which the standard TCP checksum calculation is performed, with the
  179.    pseudoheader being D[1] through D[12] and the TCP header beginning at
  180.    D[13].  Note that, for purposes of the checksum computation, the
  181.    checksum field itself must be equal to zero.
  182.  
  183.    At the end of the loop, the A goes in the first byte of the TCP
  184.    checksum and B goes in the second byte.
  185.  
  186.    Note that, unlike the OSI version of the Fletcher checksum, this
  187.    checksum does not adjust the check bytes so that the receiver
  188.    checksum is 0.
  189.  
  190.    There are a number of much faster algorithms for calculating the two
  191.    octets of the 8-bit Fletcher checksum.  For more information see
  192.    [Sklower89], [Nakassis88] and [Fletcher82].  Naturally, any
  193.    computation which computes the same number as would be calculated by
  194.    the loop above may be used to calculate the checksum.  One advantage
  195.    of the Fletcher algorithms over the standard TCP checksum algorithm
  196.    is the ability to detect the transposition of octets/words of any
  197.    size within a datagram.
  198.  
  199. APPENDIX II:  The 16-bit Fletcher Checksum Algorithm
  200.  
  201.    The 16-bit Fletcher Checksum algorithm proceeds in precisely the same
  202.    manner as the 8-bit checksum algorithm,, except that A, B and the
  203.    D[i] are 16-bit quantities.  It is necessary (as it is with the
  204.    standard TCP checksum algorithm) to pad a datagram containing an odd
  205.    number of octets with a zero octet.
  206.  
  207.    Result A should be placed in the TCP header checksum field and Result
  208.    B should appear in an TCP Alternate Checksum Data option.  This
  209.    option must be present in every TCP header. The two bytes reserved
  210.    for B should be set to zero during the calculation of the checksum.
  211.  
  212.    The checksum field of the TCP header shall contain the contents of A
  213.    at the end of the loop.  The TCP Alternate Checksum Data option must
  214.    be present and contain the contents of B at the end of the loop.
  215.  
  216. BIBLIOGRAPHY:
  217.  
  218.    [BrBoPa89]     Braden, R., Borman, D., and C. Partridge, "Computing
  219.                   the Internet Checksum", ACM Computer Communication
  220.                   Review, Vol. 19, No. 2, pp. 86-101, April 1989.
  221.                   [Note that this includes Plummer, W. "IEN-45: TCP
  222.                   Checksum Function Design" (1978) as an appendix.]
  223.  
  224.  
  225.  
  226. Zweig & Partridge                                               [Page 4]
  227.  
  228. RFC 1145             TCP Alternate Checksum Options        February 1990
  229.  
  230.  
  231.    [Fletcher82]   Fletcher, J., "An Arithmetic Checksum for Serial
  232.                   Transmissions", IEEE Transactions on Communication,
  233.                   Vol. COM-30, No. 1, pp. 247-252, January 1982.
  234.  
  235.    [Nakassis88]   Nakassis, T., "Fletcher's Error Detection Algorithm:
  236.                   How to implement it efficiently and how to avoid the
  237.                   most common pitfalls", ACM Computer Communication
  238.                   Review, Vol. 18, No. 5, pp. 86-94, October 1988.
  239.  
  240.    [Sklower89]    Sklower, K., "Improving the Efficiency of the OSI
  241.                   Checksum Calculation", ACM Computer Communication
  242.                   Review, Vol. 19, No. 5, pp. 32-43, October 1989.
  243.  
  244. Security Considerations
  245.  
  246.    Security issues are not addressed in this memo.
  247.  
  248. Authors' Addresses
  249.  
  250.    Johnny Zweig
  251.    Digital Computer Lab
  252.    University of Illinois (UIUC)
  253.    1304 West Springfield Avenue
  254.    CAMPUS MC 258
  255.    Urbana, IL 61801
  256.  
  257.    Phone:  (217) 333-7937
  258.  
  259.    EMail:  zweig@CS.UIUC.EDU
  260.  
  261.  
  262.    Craig Partridge
  263.    Bolt Beranek and Newman Inc.
  264.    50 Moulton Street
  265.    Cambridge, MA 02138
  266.  
  267.    Phone: (617) 873-2459
  268.  
  269.    EMail: craig@BBN.COM
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Zweig & Partridge                                               [Page 5]
  283.